home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 15337 < prev    next >
Encoding:
Text File  |  1996-08-05  |  3.7 KB  |  117 lines
  1. Path: ix.netcom.com!news
  2. From: jhewett@ix.netcom.com (Jerry Hewett)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Did I Miss Something?
  5. Date: Thu, 04 Apr 96 18:06:20 GMT
  6. Organization: Netcom
  7. Message-ID: <N.040496.100620.06@ix.netcom.com>
  8. References: <N.040396.105136.51@ix.netcom.com>
  9.  <4k01o7$sl2@grimsel.zurich.ibm.com>
  10. NNTP-Posting-Host: tem-ca1-07.ix.netcom.com
  11. X-NETCOM-Date: Thu Apr 04 12:05:48 PM CST 1996
  12. X-Newsreader: Quarterdeck Message Center [2.00]
  13.  
  14. Keith Whittingham <wgk@zurich.ibm.com> writes:
  15.  
  16. > There is no memory allocation for the string: your assumption is wrong. I
  17. > think the code you're are being given is not a very good example! The
  18. > constructer would be better written:
  19. >
  20. >  box::box(char *input_line)
  21. >  {
  22. >  length = 8;
  23. >  width = 8;
  24. >  line_of_text = strdup(input_line);
  25. >  }
  26.  
  27. So if my theory that the act of calling a constructor allocates the necessary 
  28. memory (like strdup automagically calls malloc to create space in the heap) is 
  29. in error, then the original example (line_of_text = input_line) indeed does not 
  30. carve out a chuck of RAM big enough to hold "small box"?  So even though this 
  31. works when I compile it, in actuality it is undefined behavior?
  32.  
  33. Since I posted this question yesterday I've been looking through all of the 
  34. reference books I have on hand, and discovered the following information on 
  35. page 126 of Herbert Schildt's _C++ Nuts & Bolts_:
  36.  
  37. ----<snip>----
  38.  
  39.     "As you know, C++ allows string constants enclosed between double
  40.      quotes to be used in a program.  When the compiler encounters such
  41.      a string, it stores it in the program's string table and generates
  42.      a pointer to the string.  For this reason, the following program is
  43.      correct and prints 'one two three' on the screen:"
  44.  
  45.     #include <iostream.h>
  46.  
  47.     main()
  48.     {
  49.         char *p;
  50.  
  51.         p = "one two three";
  52.  
  53.         cout << p;
  54.  
  55.         return 0;
  56.     }
  57.  
  58. ----<snip>----
  59.  
  60. Well, this is all certainly news to me!  :-)
  61.  
  62. (please bear with me on this -- I'm really trying to make sure I understand 
  63. what's going on here so that I can prevent "Stupid Programmer Behavior" in my 
  64. own code)
  65.  
  66. What Schildt is apparently saying is that even though "char *p" is NOT being 
  67. declared as "const char *p", the compiler will treat it as a constant by adding 
  68. it to a string table in memory and returning a pointer to it?  Therefore, the 
  69. original snippet of sample code...
  70.  
  71. > class box {
  72. >     int length;
  73. >     int width;
  74. >     char *line_of_text;
  75. > public:
  76. >     box(char *input_line);
  77. >     void set(int new_length, int new_width);
  78. >     int get_area(void);
  79. > };
  80. > box::box(char *input_line)
  81. > {
  82. >     length = 8;
  83. >     width = 8;
  84. >     line_of_text = input_line;
  85. > }
  86. >
  87. > main()
  88. > {
  89. >     box small("small box ");
  90. >
  91. > }
  92.  
  93. ..is correct according to the rules of C++ (even though it possibly could have 
  94. been defined more clearly to prevent folks like me from misunderstanding what's 
  95. going on ;-)?
  96.  
  97. > Of course the C++ biggots will insist on using new and delete instead of
  98. > strdup and free but that's all a matter of style.
  99.  
  100. I agree with everything in your revised version of the code, and probably would 
  101. have done something similar myself, except that I probably would have used 
  102. "new" and "delete" to help me along in the learning process.  But hashing this 
  103. kind of strange (to me, at least :-) behavior out with other programmers has 
  104. always helped me grasp and hold onto new concepts and ideas.  At least I 
  105. *think* I have a better understanding of what's going on now...
  106.  
  107. > In general C++ itself does no more for you than C, no automatic memory
  108. > allocation, no garbage collection etc. All in all that should lead to
  109. > faster code but you do have to be thorough when writing the stuff.
  110.  
  111. Especially when an example like the one I posted confuses the heck out of a 
  112. newcomer to C++ like me! :-)
  113.  
  114. Jerry H.
  115.  
  116.  
  117.